Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@go.mod`:
- Line 16: The github.com/docker/docker dependency is deprecated and will not
receive security patches. Remove or replace the github.com/docker/docker
v28.5.2+incompatible line in go.mod and add the maintained replacements
github.com/moby/moby/client and github.com/moby/moby/api modules with
appropriate versions. Additionally, update all import statements throughout the
codebase that currently reference github.com/docker/docker packages to use the
corresponding github.com/moby/moby/client and github.com/moby/moby/api packages
instead.

In `@internal/tools/docker_exec.go`:
- Around line 299-314: The code discards errors from two critical operations:
the StdCopy stream copy and the ContainerExecInspect call. When the `copyDone`
channel receives a signal in the first select case, capture any error from the
underlying stdcopy.StdCopy operation and return it if it exists. Additionally,
after the ContainerExecInspect call, check if `ierr != nil` (not just the
condition on line 311) and return the error instead of silently succeeding. This
ensures that I/O failures and inspect operation errors are properly propagated
rather than marked as successful executions.

In `@internal/tools/switch_env.go`:
- Around line 74-98: The PTY backend created by ptyManager.createDocker() does
not hold its own reference to the Docker container, so when switch_env calls
closeIfRemote(prev), the container can be stopped even while a PTY session is
actively reading/writing to it. Fix this by having ptyManager.createDocker()
call AcquireDockerContainer() to acquire and hold a reference to the container
at session creation time, then store this reference in the dockerPTYBackend
structure. Update the PTY backend's Close() method to release this container
reference when the session terminates, ensuring the container remains alive for
the duration of the active terminal connection.

In `@internal/web/pty.go`:
- Around line 104-118: The createDocker function and related Docker operations
use context.Background() which doesn't support request cancellation, causing
goroutines to block indefinitely if the Docker daemon stalls. Add a
context.Context parameter as the first parameter to the createDocker function
signature, then replace all context.Background() calls within createDocker and
the related functions at lines 131-135 and 313-317 with the passed context or
bounded child contexts with appropriate timeouts. Finally, update all callers of
createDocker in internal/web/server.go to pass the request context instead of
creating fresh background contexts.
- Around line 252-256: The code currently treats any websocket TextMessage
starting with `{` as a control message and consumes it via the
handleControlMessage call with a continue statement. This causes invalid JSON or
non-resize JSON to be dropped instead of being sent to the shell. Fix this by
only consuming messages that are actually recognized control messages. Modify
the logic around the check for msg[0] == '{' to validate that the message is a
legitimate control message (such as a resize command with the proper JSON
structure) before calling handleControlMessage and using continue. If the
message is not a recognized control message, allow it to fall through to the
normal shell input handling instead of discarding it. Apply this fix to both
occurrences of this pattern mentioned in the comment.

In `@internal/web/remote.go`:
- Around line 385-404: The config read-modify-write section in this handler
incorrectly uses s.mu instead of the dedicated s.cfgMu mutex. Replace all
s.mu.Lock() and s.mu.Unlock() calls in this handler block (including the early
unlock after the s.cfg == nil check and the final unlock after SaveConfig) with
s.cfgMu.Lock() and s.cfgMu.Unlock() respectively. This ensures proper
serialization of concurrent config modifications across all handlers and
prevents races with handlers that correctly use s.cfgMu.
- Around line 167-192: The remoteConnRegistry only performs lazy cleanup via
sweepLocked() when add() is called in connectDocker, causing abandoned
connections and expired entries to linger indefinitely. More critically, on
server shutdown (around lines 338-345), remoteConns is never cleaned up, leaving
Docker container reference counts unrelemented. Add a closeAll() method to the
remoteConnRegistry type that iterates through and closes all pending connections
and their executors, then invoke this method during server shutdown before
calling srv.Shutdown(). Additionally, consider implementing a background
goroutine using a ticker that periodically invokes the sweep mechanism to
proactively enforce TTL cleanup rather than relying exclusively on lazy
evaluation triggered by add().

In `@web/src/components/RemoteConnectWizard.vue`:
- Around line 577-618: The Docker wizard template in RemoteConnectWizard.vue is
using four new i18n keys (wizard.dockerConnection, wizard.dockerDesc,
wizard.selectContainer, wizard.noContainers) that are missing translations in
the non-English locale files. Add these four keys with appropriate translations
to each of the locale files ja.ts, ko.ts, zh-Hans.ts, and zh-Hant.ts, following
the same structure and naming convention as other wizard-related translation
keys already present in those files.

In `@web/src/i18n/locales/en.ts`:
- Around line 441-449: The Docker wizard keys (container, dockerConnection,
dockerDesc, selectContainer, noContainers, refresh, running, stopped) have been
added to the English locale file but are missing from the non-English locale
files. Add these same keys with appropriate translations to the zh-Hans.ts,
zh-Hant.ts, ja.ts, and ko.ts locale files, maintaining the same object structure
and key names as in the English version. Ensure all keys are present and
properly translated in each non-English locale to avoid runtime translation
mismatches.

---

Outside diff comments:
In `@internal/web/engine.go`:
- Around line 346-348: When s.newRemoteEngine() returns an error in the error
handling block after the executor has been acquired, the remote executor (the
exec parameter) needs to be properly closed to release the Docker/SSH resource.
Add a cleanup call to close the executor before returning the error, ensuring
the container reference is released and expected auto-stop behavior is not
skipped.

In `@internal/web/pty.go`:
- Around line 246-264: When conn.ReadMessage() fails and the loop breaks, the
backend reader goroutine is left stale and blocked, consuming resources and
potentially receiving output meant for new connections. After the break
statement in the WebSocket read loop (where err != nil), add cleanup logic to
close or signal sess.backend before waiting on the done channel. This ensures
the backend reader goroutine unblocks and releases resources, preventing stale
readers from interfering with new WebSocket connections. If PTY sessions are
meant to survive reconnects, implement explicit attach/detach ownership tracking
so that old readers are properly detached before new WebSocket clients can
attach.

---

Nitpick comments:
In `@internal/remote/docker.go`:
- Around line 27-34: Wrap both error returns with context using fmt.Errorf to
help callers identify which operation failed. When the tools.DockerClient() call
returns an error, wrap it with a descriptive context prefix using fmt.Errorf
with the "%w" verb. Similarly, when the cli.ContainerList() call returns an
error, wrap it with a context prefix using the same pattern. Make sure to add
"fmt" to the imports if not already present, then replace both bare error
returns with wrapped versions that include meaningful context about which
operation failed.

In `@internal/tools/docker_exec.go`:
- Around line 49-52: The dockerRefMu variable is declared as sync.Mutex but
should be sync.RWMutex to support read-heavy access patterns (such as the reads
at line 113). Change the type declaration of dockerRefMu from sync.Mutex to
sync.RWMutex, then update all lock usage throughout the file to use
RLock/RUnlock for read-only operations on dockerRefs and Lock/Unlock for write
operations to maintain proper concurrency control.